Ml and the Address Operator

ML supports references to objects through mutable ref cells: A program can create a ref cell from an object, and subsequently replace the object accessible through the cell by another. Unfortunately, ref cells, when compared to mechanisms for handling mutable data in other programming languages , impose awkward restrictions on programming style. Moreover, introducing ref cells into a program after the fact requires pervasive changes. This paper proposes a language extension to ML with pointers, a safe mechanism for dealing with mutable objects. The extension avoids the style and maintenance problems inherent in the ref cell mechanism. Modern programming languages such as Java, Scheme, and ML, use \safety" as an advertisement: A program cannot crash the system by dereferencing an invalid address. This achievement is largely due to two improvements over low-level languages such as C, Modula-2, or Pascal: Automatic Storage Management Garbage collection obviates the need for free or dispose calls which are dangerous because they make formerly valid pointers invalid. References are Boxes A program cannot take the address of an object and write through it later. Instead, it must create a reference (or box) for mutable data whose contents the program may change and whose extent is unlimited; the object in the box itself still does not become mutable. This last property appears in diierent forms across the spec-trum|Standard ML has ref cells, Objective Caml has record elds which are mutable by declaration, in Java all record elds and bindings are mutable, and Scheme has mu-table bindings, pairs and vectors. The expressiveness of all of these mechanisms is essentially the same. References-as-boxes have a strong bearing on programming pragmatics: While functional programming practice discourages the use of mutable data altogether, it is not always possible to do without it. Moreover, as appealing as the merits of pure functional programming are, mutable data structures are a powerful and frequently useful abstraction 1]. In ML, in order for a value to become mutable, the programmer must replace it by a reference|this means changes at all of its occurrences. This is syntactically inconvenient and generally awkward|the mutability of a value is of no consequence for most of its uses. Yet this fact becomes painfully obvious because the value becomes available only by dereference. For writing new programs, adding references is merely a nuisance. However, the issue becomes more serious when changing old ones, because the ensuing changes are usually far-reaching …